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Abstract— The Mars Science Laboratory (MSL) Project is 
an aggressive mission launching in 2009 to deliver a new 
generation of rover safely to the surface of Mars and 
conduct comprehensive in situ investigations using a new 
generation of instruments. This system will be designed to 
land with precision and be capable of operating over a large 
percentage on the surface of Mars. It will have capabilities 
that will support NASA’s scientific goals into the next 
decade of exploration. The MSL Technology Program is 
developing a wide-range of technologies needed for this 
Mission and potentially other space missions. The MSL 
Technology Program reports to both the MSL Project and 
the Mars Technology Program (MIP). The dual reporting 
process creates a challenging management situation, but 
ensures the new technology meets both the specific MSL 
requirements and the broader Mars Program requirements. 

MIP is a NASA-wide technology development program 
managed by the Jet Propulsion Laboratory (JPL) and is 
divided into a Focused Program and a Base Program. The 
Focused Technology Program addresses technologies that 
are specific and critical to near-term missions, while the 
Base Technology Program addresses those technologies that 
are applicable to multiple missions and which can be 
characterized as longer term, higher risk, and high payoff 
technologies. The MSL Technology Program is under the 
Focused Program and is tightly coupled to MSL’s mission 
milestones and deliverables. The technology budget is 
separate from the flight Project budget, but the technology’s 
requirements and the development process are tightly 
coordinated with the Project. 

The Technology Program combines proven management 
techniques of flight projects with commercial and academic 
technology management strategies, to create a technology 
management program that meets the near-term requirements 
of MSL and the long-term requirements of MTP. This 
paper examines the initiation of 2002 MSL Technology 
program. Some of the areas discussed in this paper include 
technology definition, task selection, technology 
management, and technology assessment. 
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1. Introduction 

The Mars Science Laboratory (MSL) Project is an 
aggressive mission launching in 2009 to deliver a new 
generation of rover safely to the surface of Mars and 
conduct comprehensive in situ investigations using a new 
generation of instruments. This system will be designed to 
land with precision and be capable of operating over a large 
percentage on the surface of Mars. It will have capabilities 
that will support NASA’s scientific goals into the next 
decade of exploration. 

This paper examines our plans at the Jet Propulsion 
Laboratory (JPL) to define and initiate MSL’s Technology 
Program. When we initiated this Technology Program in 
2002, we were unable to locate guidelines or examples of 
how other missions in pre-formulation developed their 
technologies. To address this issue and provide other 
projects and programs with an example of a technology 
implementation plan, this paper reviews the detailed 
processes MSL used to initiate its program. In fact, early 
versions of this paper were provided to other projects at JPL 
and the Goddard Space Flight Center (GSFC) to help them 
develop their technology plans. These projects eventually 
implemented elements of MSL’s Technology Plan. 

The Mars Technology Program (MTP) is comprised of a 
Focused Technology Program and a Base Technology 
Program [1]. The Focused Technology Program addresses 
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technologies that are specific and critical to near-term 
missions, while the Base Technology Program addresses 
those technologies that are applicable to multiple missions 
and which can be characterized as longer term, higher risk, 
and high payoff technologies. MSL’s Technology Program 
is under the MTP Focused Technology Program and is 
roughly an $80 million effort to develop the technology 
needed to meet the unique requirements of the MSL 
Mission. 

The MSL mission introduces a number of significant 
technological innovations to enable the following 
capabilities: 1) dramatically increased landing precision and 
accessibility to the Martian surface by landing within a 10- 
kilometer major axis ellipse between 60° N and 60° S 
latitudes, and up to +2.5 kilometer altitude, 2) extended 
mobility range adequate to ensure representative 
measurement of diverse sites, at scales of several 
kilometers; with a goal to demonstrate a total traverse 
distance of greater than 10km, 3) long-lived mobility asset, 
ensuring operability for a minimum of one Mars year (2 
Earth years), and 4) operation of an analytical science 
laboratory capable of definitive analysis of the mineralogy, 
chemistry, and isotopic composition of surface and near- 
surface materials; including the assessment of biological 
potential of the landing site. These technology innovations 
carry forward into future missions in the second decade of 
this century. 


2. MSL Technology Overview 

MSL is equipped with an onboard science laboratory that 
performs in-situ analytical experiments. In addition to being 
a full science mission, MSL will provide feed-forward 
technologies that are required by future missions to land 
large payloads and operate for a long time on the surface of 
Mars. An example of such a future mission is the Mars 
Sample Return mission [1]. 

There are two main technology areas that are required for 
the MSL mission: Entiy, Descent, and Landing (EDL) 
capability and Surface System technologies. EDL 
technology includes guidance, deceleration, and landing 
technologies and surface system technology includes rover, 
long-life, and sample preparation and distribution 
technologies. The following paragraphs describe these 
technologies. 


Authors note : The information in this paper is based on 
conceptual designs (at this writing, approximately two years 
prior to the project preliminary design review (PDR)). 
Readers should appreciate that actual capabilities of the 
landed mission may ultimately be less than or greater than 
described here. 


2. 1 Entry, Descent, and Landing (EDL) 

One of the main goals of the MSL technology program is to 
develop the capability to land safely near any chosen site 
(including higher elevations) in order to provide a near 
global access to Mars. To achieve this ability to land safely 
at any locality on Mars, the entire process of entry, descent 
and landing was reviewed and technology innovations 
initiated to provide the needed capabilities. Figure 2-1 
shows the EDL technology goals. 


♦ ENTRY EDL 



Figure 2-1 - MSL’s EDL Technologies Goals. 


Past Mars Mission utilized radio-based approach navigation, 
no control of the lift vector during entry, a single stage 
parachute, and only limited hazard tolerance (airbags or 
landing ruts). There was no hazard detection/avoidance 
capability. Variants of this approach were used on Viking 
and Pathfinder and are currently in use on the 2003 Mars 
Exploration Rover (MER) mission. The errors in approach 
navigation propagate through the trajectory, resulting in a 
landing error ellipse ranging from 100 km cross range to 
300 km along the downrange vector. The payload mass that 
can be delivered using existing or anticipated launch 
vehicles with this system is limited to - 200 kg. 

Precision landing reduces the risk of encountering 
hazardous areas such as large craters and steep canyons at 
any given region of Mars where it is desired to land. The 
goal is to develop new technology to reduce the landing 
error ellipse to smaller than 5 x 10 km. In addition the 
payload mass will be raised to ~ 900 kg. To achieve this 
goal, each step of the EDL process is upgraded with new 
technology. Each step is developed with advanced 
technology, with systems engineering used to assure that all 
the pieces fit together. To achieve this goal, three 
complementary technologies are in development: Precision 
Landing; Hazard Avoidance; and Robust Landing. 



Precision Landing — A lifting entry vehicle is in 
development with L/D ~ 0.25 (lift/drag) that is capable of 
actively guiding itself from entry to parachute deployment 
despite uncertainties in the entry conditions, atmospheric 
density profile, winds and aerodynamic performance. The 
two-stage parachute system includes a supersonic chute and 
a subsonic chute. Improved descent propulsion is achieved 
by recapturing Viking technology with new improved 
components. 

Hazard Detection and Avoidance - Hazard avoidance 
provides an “eyes wide open” capability at landing. The 
overall process is illustrated in Figure 2-1. This makes it 
possible to make adjustments to the landing location to 
avoid large craters, large rocks and steep local slopes. MSL 
is developing an integrated terminal guidance, navigation, 
and control system that predicts the descent flight path after 
the subsonic parachute is deployed, detects hazards such as 
rocks and slopes using active sensors, and after jettisoning 
the parachute, steers the lander to a safe landing area. A 
RADAR sensing system for 0-7 km altitudes is in 
development to generate initial terrain maps at 500m 
altitude and create initial position estimates of the landing 
area at ~ 7 km altitude. This system provides more time for 
the lander to be laterally maneuvered to avoid undesirable 
landing sites. 

Robust Landing - Once landing is committed to, this 
technology makes it possible to tolerate the unexpected and 
provide resilience to failures in either precision landing or 
hazard avoidance systems. The baseline plan is to get away 
from the landing pallet system and all its mass, egress, and 
design problems and develop a sky-crane system that is less 
complex and provides better technology feed forward 
capability (for Mars Sample Return). 

2.2 Surface System Technologies 

These technologies include all the technologies that enable a 
rover to travel long distances, place instruments 
autonomously, and analyze samples in its onboard 
laboratory. The rover and its instrumentation must last at 
least one Martian year. 



Figure 2-2 - MSL’s Surface System Technologies 


Improved rover autonomy is developed to enable safe 
navigation as well as autonomous science operations for 
Mars surface missions. The strategy is to integrate 

technologies from MTP’s Base Program that are 
competitively selected and integrate them to demonstrate the 
capabilities that are required for MSL. 

Long Life - A study was conducted to determine which of 
the rover components are likely to fail during the one 
Martian year mission and it revealed that there are major 
weaknesses in the area of mechanical systems, particularly 
motors and bearings. Another major area was the 
electronics which would be exposed to the extreme Martian 
temperature fluctuation. MSL has a Thermal Cycle 

Resistant Electronics (TCRE) task to improve and test 
potential hardware under realistic conditions. 

Sample Processing and Distribution Experiment (SPADE) - 
One of the main differences between MSL and past Mars 
missions is MSL’s capability to analyze Martian samples 
onboard its analytical laboratory. The laboratory consists of 
science instruments, sample acquisition, processing, and 
distribution system. 

The objective of the SPADE system is to crush rocks (0.1-1 
mm) and distribute them to various onboard science 
instruments. Cross contamination for this type of a system is 
a major concern. A technology requirement has been 
established to insure that no more than 5% contamination 
results from one sample to the next. This number can be 
decreased by processing the second sample more than once, 
thus reducing the contamination to levels below 5%. 

The previous paragraphs provided an overview of the 
technologies needed for the MSL Mission. The following 
sections describe how MSL and MTP defined, selected, and 
managed the specific technologies need by MSL. 


3. Technology Program Implementation 

The purpose of the MSL Technology Program is to retire 
technical risks while the project is in formulation and before 
it enters implementation. If a technology risk cannot be 
retired before implementation, the project still has time to 
select another technology and modify their mission concept. 
The technology program matures the most effective 
technologies while balancing each technology’s 
performance, cost, risk, and schedule. During the 
technology program, MSL matures the required 
technologies from their present Technology Readiness 
Level (TRL) that is typically between TRL 2 and 3 to a TRL 
of 6. 

TRLs are a systematic metric/measurement system that 
supports assessments of the maturity of a space technology 
and provides a method of comparing maturity between 
different types of technology. The TRL scale is from 1 to 9, 



where 1 represents a technology principle and 9 represents a 
technology flown successfully in space. Projects that are 
not technology demonstration missions typically don’t 
accept the risk of including a technology with a TRL of less 
than 6 in their design concept. TRL 6 corresponds to a 
technology functioning in a subsystem (model or prototype) 
in a relevant environment (ground or space). 

NASA’s guidelines for Project Management, NPG 7120.5B, 
states: 

The purpose of the formulation subprocess is to 
define a project concept and plan for 
implementation to meet mission objectives... the 
formulation subprocess ... assesses the 
technology requirements and develops the plans 
for achieving the technology options ... [2] 


The following sections describe how MSL defined its 
project concept, assessed its technology requirements, and 
developed its technology implementation plan. 

MSL’s technology implementation process, show in Figure 
3-1, include three major stages: technology definition, 
technology task selection, and technology management 
The following sections describe each of these efforts and 
relate them back to Figure 3-1. Figure 3-1, MSL 
Technology Implementation Plan, also lists the paragraph 
numbers of the following sections to show how the flow of 
the paper corresponds to the flow of the technology 
implementation process. 

The MSL Technology Program is complete when it 
technology matures to TRL 6. The goal of the MSL Project 
is for all its technology to reach TRL 6 by the Mission 
Preliminary Design Review (PDR) in 2005. 
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Figure 3-1 - MSL Technology Implementation Process 















3.1 Technology Definition 

The first stage of MSL’s technology implementation 
process is Technology Definition. In this stage, as described 
below, the different organizations work together and 
produce science requirements, a mission concept, a mission 
risk list, and a list of candidate technologies that reduce the 
mission risks. 


3.1.1 Development Organization - Central to 
implementing a successful technology program is an 
effective organization structure. The following section 
describes the 2002 MSL organization (shown in Figure 3-2) 
that defined and initiated the MSL technology program. 
The positions in this organization chart will be referred to as 
the implementation process is described. The roles and 
responsibilities of these positions are described below. 

At the top and center of this chart are the Science Definition 
Team (SDT) and the Mars Program System Engineering 
Team (MPSET). The SDT defines and prioritizes the 
science goals, objectives, investigations, and measurements 
of MSL. The SDT ensures that the MSL science 
requirements and mission concept are consistent with Mars 
Program science themes. The MPSET ensures that the Mars 
Program is optimized as a whole and not on a basis of 
project by project. MPSET also works with the Mars 


Technology Program (MTP) and constituent projects to 
maximize the program’s technology readiness. If a 
technology is needed for multiple missions, MPSET ensures 
that the requirements of both missions are included in the 
initial development effort. For example, an earlier Mars 
mission (MRO) developed an optical navigation (OpNav) 
camera and included the requirements of both the MRO and 
MSL missions in the development process. The minimal 
cost impact to MRO is justified by the significant benefit to 
MSL and the Mars Program. 

An interesting feature of the MSL Technology Program is 
the dual reporting structure. The MSL Focused Technology 
Manager reports to both the MSL Project Manager and the 
MTP Program Manager. The MSL Project Manager ensures 
technology meets the MSL focused requirements and the 
MTP Program Manager ensures technology meets the long- 
range requirements of the Mars Program. This inherent 
conflict actually benefits the project and the program by 
providing a checks-and-balance to many budget and 
technical decisions. 

Five Element Managers report to the MSL Technology 
Manager. The Element Managers are responsible for major 
systems in the project and ensure that the technologies 
underdeveloped are compatible with the latest mission 
concept. They also ensure the mission concept is consistent 
with the progress of the different technology tasks. 
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Figure 3-2 - 2002 MSL Technology Organization Chart 













3.1.2 Science Requirements and Mission Concept - The 
first step in technology implementation (Figure 3-1) is to 
define die technology to be developed. This may sound 
obvious and simple, but in a large organization with 
competing views, issues, and priorities, agreeing on 
technology requirements is a challenging task. 

On MSL the process began with the project working with 
both the MPSET and the SDT to develop the mission 
science requirements (Level 1). Next, the project manager, 
element managers, and different working groups 
transformed these requirements into a baseline mission 
concept (where ‘baseline’ implies the concept will change 
as the both the technology and the project definition 
matures). The project uses the baseline mission concept to 
generate the system-level performance requirements. The 
following sections concentrate on the process of converting 
the mission concept into an effective technology 
implementation plan. 


3.1.3 Mapping Requirements to Technology - The 
technology definition process continues by reviewing the 
mission concept and the system-level performance 
requirements in informal (peer) reviews, formal reviews, 
and working group meetings. These meetings defined the 
major risks and identify candidate technologies to reduce 
these risks. These risks include performance risks, costs 
risks, and schedule risks. Through MSL’s technology 
definition and selection process, the project initiated 
technology tasks that reduced risk in all three areas. 

MSL used a process for managing these risks called Defect 
Detection and Prevention (DDP) [3]. The DDP process has 
three steps: 1) determine where we want to be, 2) identify 
what could get in the way, and 3) decide how we will get 
there. MSL implemented the DDP steps and put their 
system-level performance requirements in a tree structure to 
‘determine where we want to be’ and captured as trees of 
potential failure modes ‘what could get in the way’. MSL 
then scored the impacts of these failure modes on the 
science requirements to prioritize the failure modes. From 
the list of failure modes, MSL created their initial Mission 
Risk List. 

The third step, ‘decide how we will get there’, is probably 
the most challenging and requires the most iterations with 
the project, program, and cost modeling organizations. 
Technology investments were assigned to each risk area and 
the DDP tool captured the estimate of how each risk area 
was reduced. A ‘top down’ approach, based on cost models 
and project experience, was used to estimate the cost of the 
different technology investments. A ‘bottom up’ cost 
estimate is done after a task manager is assigned and this 
process is examined in a following section. 

Each technology investment, constrained by the technology 
budget, addressed an item on the prioritized risk list. The 
risks, and their corresponding technology, include 


performance risk, schedule risk, or cost risk. Examples of 
the three types of risk and their corresponding technology 
are as follows: 1) existing engines do not meet MSL 
performance requirements so we invested in new engines, 2) 
current mission operations do not meet MSL’s extended life 
requirements so we invested in improved operations and 
science collaboration; and 3) the cost (in dollars and mass) 
to heat external electronics is high so we invested in 
temperature extreme electronics. 

The process to determine which combination of 
technologies minimize mission risk and should be funded is 
described in the following sections. 


3.2 Technology Selection 

The second stage of MSL’s technology implementation 
process is Technology Selection. This stage started with a 
list of candidate technologies and produced detailed 
implementation plans for each technology task. The MSL 
technology selection process took five months for most of 
its tasks and an additional four months to refocus and select 
the remaining tasks. The Technology Selection process is 
examined in the following paragraphs. 


3.2.1 Assign Task Managers - After MSL agreed to a 
candidate list of technologies, the Mars Program, the MSL 
Project, Element Managers, and functional managers 
together selected and approved Task Managers to lead each 
development effort. Task Managers are typically 
technologists with mixed levels of flight project experience. 
Since MSL is a focused technology effort, these tasks 
managers became integral members of the project team. 
Experienced Element Managers work with each Task 
Managers to ensure projects requirements are meet. The 
tightly coupled technology /project environment required the 
technologist to be less autonomous and more driven by 
project cost, schedule, and performance constrains. This 
initially was challenging for technologists accustomed to 
working independently, but the common goal of a 
successful planetary mission helped unify the diverse team 
members. 


3.2.2 Prepare Task Proposals - Using the baseline 
mission concept and the system-level performance 
requirements , each task manager worked with their element 
manager to develop a presentation that proposed how their 
task would meet the mission requirements. These proposals 
were presented to the MTP Program Manager and the MSL 
Project Team. The presentations described how the task 
would improve the current state-of-the-art, for what cost, 
and in what schedule. The following is a detailed list of 
what each presentation included and why it was requested. 
As stated earlier, this detail is not needed to understand the 
MSL Technology Program, but it may be useful to another 
project initiating their technology program. 


Overview (Quad Chart) - A one slide summary of the 
proposed task including a representative picture, objectives 
summary, milestones list, organizations involved, 
collaborators, outside companies, and a subtask multi-year 
schedule including funding levels. This chart is not 
frequently updated, but it is useful for someone unfamiliar 
with the task to get a summary of the technology. 

Objectives and approach - These slides described the 
overall task objectives, quantify the current state of the art, 
and quantify the new performance goals. They also 
explained the implementation approach and provide a cost 
summaiy. In addition, the task’s milestones (or 
accomplishments) are listed. These charts provide insight to 
the reviewers on die task manager’s grasp of the problem, 
plan to solve die problem, and the metrics to show progress. 

Backup data - Included a list of questions to help the 
reviews assess the impact, risks, and procurements 
associated the task. Question 1: What is the functional 
relationship between the technology task and the mission 
goals? This question ensures that die task address a critical 
need of the project and is not just an interesting technology 
effort. Question 2: What are the assumptions, dependencies, 
and risks associated with the task? This question identifies 
any issues with the task. Question 3: Explain any outside 
procurements? This question identifies if the task needs a 
large procurement. Procurements are complex, so 
identifying them early can avoid future problems. 

Receivable/Deliverable Lists - List all die items being 
received by the task and delivered from the task to a project 
element. A significant difference between a focused 
technology task and a base technology task is the tight 
coupling of the technology task to the flight project. A 
flight project is driven by its launch date and other key 
milestones. A technology task must synchronized its 
deliverables and schedule to the flight schedule. Each 
technology task must closely track what items it expects 
from a flight system or another technology task. A problem 
in one task could ripple through multiple tasks and flight 
systems, so the project must track the dependencies. 

3.2.3 Technology Tasks Review - Approximately thirty 
technology tasks were presented to the MSL Project and the 
MTP Program in a three step process: project reviews, a 
functional organization review, and a program review. The 
project reviews included three different reviews over a 
period of two weeks. Each review refined the technology 
implementation concept and helped communicate the 
project’s requirements and mission concept. 

The second step in the task review process was the JPL 
functional organization review. This meeting gave the 
functional managers a chance to review what commitments 
the task managers were making of their organizations. It 
also provided a forum for the project and the functional 


organizations to discuss die latest technology requirements 
and mission concept. 

The third step in the task review process was the four day 
MTP Year End Review (YER). The Mars Technology 
Program (MTP) conducted this meeting and included 
reviewers internal and external to JPL and the Mars 
Program. They provided an independent assessment of the 
MSL technologies with an eye on the big picture. The 
independent reviewers are aware of technology 
development efforts at other government, university, and 
industry organizations and frequently recommended MSL 
technologists talk with other organizations. This helped 
optimize the Focused and Based Technology Programs. 

The task review process resulted in three categories of tasks: 
selected, rejected, and tasks on hold. Most tasks were 
selected, but the review process modified most 
implementation plans by changing their budget, 
development schedules, and development process. Some 
tasks were rejected because their modest improvements in 
the state-of-the-art did not justify their budget. For 
example, one task proposed reducing the size and mass of a 
flight system. However, the small improvement in size and 
mass did not warrant the cost and risk of the task. 

Several task plans lacked the necessary details and these 
tasks were put on hold until they refocused their plans. 
Most of these tasks received a low level of funding while 
they refined their concept and created new implementation 
plans. These tasks were eventually funded, but some with a 
dramatically different scope and implementation plan. 


3.2.4 Technology Development Agreements (TDA) - 

Once a technology task was selected, task managers and 
their element managers developed Technology 

Development Agreements (TDA). A TDA is a roadmap of 
the process to mature a technology from its current TRL to 
TRL 6. They also contain specific test protocols for each 
TRL transition as well as the associated costs, schedules, 
and facilities to achieve each TRL transition. These 
Technology Development Agreements (TDA) and their 
related test protocols represent a process that is 
performance-oriented and paced by the TRL transitions. To 
maximize the likelihood of meeting the overall schedule and 
budget, each technology task was assigned reserve funds to 
cover unforeseen problems. Reserves were assigned by the 
MTP Program Manager and the MSL Element Managers 
based on the risks of each tasks. The reserves are reviewed 
at the monthly management reviews (MMR), which are 
described later in this paper. 

A TDA is a web-based technology management tool that 
captures the technical and programmatic information related 
to a technology task. NASA Headquarters requires JPL and 
other NASA Centers to complete an annual technology 
inventory. TDAs capture the information required by this 
technology inventory. 


The following is a detailed list of what is in a TDA and why 
it was requested. As stated earlier, this detail is not needed 
to understand the MSL Technology Program, but it may be 
useful to another project initiating their technology program. 

Introduction - Describes the technology, assesses the state- 
of-the-art, and defines the current TRL. 

Objectives - Describes the task’s technical objectives and 
goals. In addition, this field defines the specific mission 
requirements this task will enable. This section documents 
how a task meets mission requirements. 

Technical Approach - Describes the methodology and 
approaches to conduct die proposed development. Define 
the products and/or expected results. Provides information 
on technology development approaches such as analysis, 
experiment, field testing, and, if applicable, flight 
validation. This field provides reviewers with an 
understanding of how a task will be implemented. 

Significance - Explains how the task will contribute to a 
NASA Mission. Examples are mission enabling, mission 
enhancing, increasing safety margin, reducing mass, 
lowering mission cost, etc. Mention possible applications to 
other missions. Describes the technology’s current 
performance level and what level of performance the new 
technology will achieve. This field ensures the task is tied 
to a mission requirement and not simply an interesting 
technology development effort. 

Milestones and Deliverables - Identifies die dates when 
major milestones will be achieved. At least three milestones 
are required in each fiscal year of the task. The list includes 
events, dates, and descriptions. This field provides the 
metrics that will measure die progress of the task. 

Funding Distribution - Lists the type of budget elements 
(people, parts, etc), who is being funded, which fiscal year, 
the yearly totals, and the total to complete. This field is 
completed after the task manager completes the budget 
estimate tool (Friendly Front End, FFE). The FFE tool is 
described later in this section. 

Documented Partnerships/Cooperative Agreements - 
Describes any formal partnerships, cooperative agreements, 
or other agreements that involve this task. However, 
proprietary or partner sensitive information are not to be 
included in this field. 

Comments - The following questions determine the tasks 
funding sensitivity, work breakdown, task dependencies, 
and other issues associated with the task: 1) What is the 
impact if funding is increased by 20% and decreased by 
20%? 2) What are the priorities of the different sub-tasks? 
3) What is the task’s probably of success and the backup 
plan if not successful? 4) How is this technology dependent 
on other development efforts? 5) Can the technology scale 
for different configurations and what is the impact on mass 


and power? 6) What are the technology’s interfaces and are 
they standard? 7) Describe any out-of-house efforts related 
to this task and at what level of funding. 8) What 
procurements are planned and what is the acquisition plan? 

Infusion Plan - Defines the plan for applying the 
technology developed in this task to a practical 
implementation. Final implementation includes either a 
flight project or a ground application. Unlike base 
technologies, the infusion plans for MSL’s focus 
technologies, are driven by the element managers, but this 
field captures the initial plan. 

Reporting Plan - Defines the plan for reporting 
status/progress on this task to management. This should 
include task reviews, non-advocate reviews, project review, 
written reports and publications. Again, MSL drives the 
reporting plan for its focused technologies, but this field lets 
task managers know what to expect in the future. 

Commercialization Plan - Defines the plan for transferring 
the technology developed in this task to commercial use. If 
appropriate, this field identifies the industry partner teaming 
on the commercialization effort. 

Approval - The TDA sequence of approval is: Task 
Manager, Element Manager (or Level- 1 Manager), Section 
Manager, and Project Office. Other members of the project 
team, including members of the science team, review the 
technologies at the initial proposal review and the periodic 
status reviews. 

After the TDA is approved, the task implements their 
technology development plan. The TDA is moved under 
Configuration Management (CM) control and any future 
changes require approval from MSL’s Change Control 
Board (CCB). The MSL CCB is discussed later in this 
section. TDAs are reviewed at the end of every fiscal year 
and changes are made to reflect the technology development 
updates for the next fiscal year. 


3.2.5 Technology Budget Worksheet (FFE) - Each task 
is given a fixed amount of money to develop its technology. 
The TDA captures the cost estimate to complete the task 
including purchases, travel, subcontracts, and manpower. 
The data for these fields are generated by the Friendly Front 
End (FFE), a financial spreadsheet tool that collects all the 
budget information for the technology development task. 
The FFE permits detailed cost estimates with the rates and 
factors are incorporated into the software. The FFE 
estimates: workforce, procurements / subcontracts, and 
travel / services. 

Every month, MSL’s Project Resource Analysts (PRA) 
generates financial reports for each technology development 
task and each Project Element. These reports list the actual 
spending, compare the actual costs to the planned budget, 
and flag any variances. If a technology development task is 


under-running or overrunning, the task manager must 
explain the discrepancy at the next monthly management 
review (MMR) and assess the impact to both the technology 
task and the MSL Project. 


3.3 Technology^ Management 

The third stage of MSL’s technology implementation 
process is Technology Management . This stage begins 
when the technology tasks are approved and continues until 
the tasks are completed. A task is completed when it 
reaches a Technology Readiness Level (TRL) of 6, which 
typically requires three years. Each task manager defines 
how their technology will reach TRL 6 (technology 
demonstrated in a relevant ground or space environment). 

3.3.1 Management Attention - A number of research 
studies show increased management attention improves the 
performance of an effort and increases the likelihood of 
success. The following paragraphs examine two such 
studies and describe how we applied these studies to our 
technology program. 

Timing and Impact of Management Attention - Hayes, 
Wheelwright, and Clark [4,5] examine the relationship 
between the timing of management attention and the ability 
to influence a project’s outcome. The results of this 


research, shown in Figure 3-3, highlight that organizations 
typically devote management attention to a product late in 
its development cycle when it is difficult to influence the 
outcome. Management traditionally concentrates on 
projects that are closest to their launch date, whether it is a 
product launch or a satellite launch. However, the closer to 
a launch date the more difficult and expensive it is to make 
changes. 

On MSL, we devoted considerable management attention to 
the technology program earlier in its development cycle to 
more effectively influence its outcome. We conducted 
initial project, program, functional, and independent 
reviews. We also held regular element, project, and 
program reviews. In addition, we conducted frequent one- 
on-one technology manger and task manager discussions to 
better understand technology issues, constraints, and 
dependencies. The periodic reviews are described later in 
this section. 

Frequently technologists are left alone in a lab to develop 
their technology and are not engaged until their deliver date 
approaches. Some technologists like this independence, but 
on MSL many of the technologists appreciated being more 
involved in the day-to-day activity of a planetary mission. 
MSL, with its tight budget and schedule, could not wait for 
the delivery of a technology and hope it fit into their system 
design, so we were significantly involved in the early phases 
of technology development. 
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Figure 3-3 - The Timing and Impact of Management Attention and Influence [4] 



Hawthorn Effect - In a research project (1927 - 1932) at the 
Hawthorne Plant of the Western Electric Company in 
Cicero, Illinois, Harvard researchers (Mayo, Roethlisberger, 
and Dickson) disco ved that process operators, who knew 
their process performance was being measured, actually 
performed better [6]. One conclusion from the study was 
that workers were pleased to receive attention from the 
researchers who expressed an interest in them. On MSL, 
technologists frequently expressed gratitude with our 
interest in their technology development. MSL is one of the 
flagship missions at JPL and technologists appreciated 
being more involved in this exciting mission to Mars. 

On MSL, we measured the performance of technologists 
through weekly and monthly reviews (discussed in the 
following sections). We paid close attention to 
accomplishments, budgets, and deliverables. Asking 
technologists to report progress periodically encouraged 
them to have something good to report and helped drive 
productivity. 


3. 3. 2 Weekly Element Meetings - The Element Managers 
are responsible for organizing and conducting weekly 
technical meetings of the technologies in their element. The 
appropriate task managers and system engineers support 
these weekly technical meetings. These meetings discuss 
the technical progress of the technology tasks, examine the 
dependencies of the different tasks, and review both the 
impact of the technology on the project’s concept and the 
impact of the maturing project concept on the technology. 

During the program, the Element Managers track the 
progress of both the mission concept and the technology 
development efforts. As the mission concept changes, the 
technology requirements are updated, and as the technology 
effort makes progress, the mission concept is updated. 


3.3.3 Monthly Management Reviews (MMR) - The MSL 
Technology MMR is organized and conducted by the MSL 
Project Manager and usually proceeds the MSL Project 
MMR. The MMRs are supported by the line organizations, 
the Program Office, and collaborating NASA centers. The 
MMR reviews technical progress (planned v. actual), action 
items, issues, budgets, schedules, and deliverables. 
Reserves, Risk Lists, Lien Lists, and other status charts are 
also reviewed at the MMRs. 

The MMR is supported by the project and the functional 
organizations, but every quarter the MMR is opened to a 
broader audience. These Quarterly Reviews replace that 
month’s MMR. The Element Managers prepare and present 
at the Quarterly Reviews for their respective technical areas. 
The participants include MSL Project staff, NASA Program 
Executives, representatives from collaborating NASA 
Centers, line management, and technology customers 
(project and pre-project managers). 


3.3.4 Technology Change Process - As the MSL 
technology tasks proceed and as the MSL Project concept 
matures, changes to the technology tasks are inevitable. In 
addition, the MSL technology program is managed by both 
the MSL Project, and the MTP Program, each with a 
slightly different focus. MSL desires to optimize the project 
and MTP desires to optimize the program. The technology 
change control process (shown in Figure 3-4) involves all 
impacted parties in the change process and balances the 
healthy tension between the MSL Project and the MTP 
Program. 

The CCB meetings are convened on an as-needed basis by 
the Technology Manager to examine any open Technology 
Change Requests (TCR) in a systematic manner. The 
meetings examine a TCRs impact on the project’s risk, cost, 
schedule, and performance profile. The CCB ensures that 
all affected parties are cognizant of the changes and have a 
voice in the decision making process. The MSL Project 
Manager and MTP Program Manager chair the CCB and 
have authority to approve any changes which do not affect 
the projects Level 1 requirements. Advisor members of the 
CCB include the Technology Manager, the Element 
Managers, and the project Chief Engineer. 

The MSL Technology Program maintains budget reserves to 
cover changes and other problems with the technology 
program. The lien list and the technology budget reserves 
are reviewed at the Change Control Board (CCB) meetings. 
The CCB balances the projects and the technology 
program’s risk, cost, schedule, and performance. The CCB 
can decide to approve or disapprove a TCR. The CCB can 
also decide to keep the TCR open and review it again at the 
next CCB meeting. Projects are reluctant to spend reserves 
early in the fiscal year, but later in the year when potential 
problems are better understood, an existing lien may be 
approved. 

In addition to reviewing changes, if a technology task is not 
performing due to cost, schedule, performance, or risk 
issues, the CCB can decide that the task’s performance and 
priority do not warrant spending reserves. Another option is 
to cancel a technology task, adopt the current state-of-the-art 
performance, and fund a more promising effort on the 
technology lien list. The lien list and the different funding 
options provide a sense of urgency to the task managers to 
keep their tasks on track. 

3.3.5 MTP Year-End Review (YER) - The MTP Program 
Manager organizes an October year-end review and 
assembles a peer review panel. The panel includes 
appropriate technical and programmatic personnel from 
JPL, NASA centers, NASA Headquarters, and universities. 
The MTP Program Manager or his designee chairs the peer 
review panel and provides a summary of review results and 
recommendations to the MSL Project Manager. 



Figure 3-3 - The MSL Technology Change Control Flow 


As mentioned in an earlier section, MTP used the 2002 
year-end review to independently asses the MSL 
Technology Program and to serve as the final gate before 
the program transitioned into implementation. 

3.3.6 Technology Readiness Certification Review - 
Traditionally, a major issue with NASA technology 
programs is there in ability to successfully infuse 
technology into a flight project. To help solve this problem, 
the MSL technology program is a focused program and 
includes the MSL Project Team in the selection and 
implementation of the technologies. The initial infusion 
plans are also captured in the task’s TDA. 

In addition, to help accelerate and simplify the technology 
infusion process, MSL established a Technology Readiness 
Certification Review (TRCR) process. In this process, the 
Task Manager prepares a data package on their technology 
and presents the package to the project near the completion 
of the task. The package includes the criteria the task used 
to meet their TRL 6 requirements. For each technology, the 
TRCR package includes all the design, fabrication, 
assembly, and test information the project needs to 
implement the technology. 


4. Technology Management Tools 

The previous sections described the first year of the MSL 
technology program and examine the processes for defining, 
selecting, and managing the focused technology tasks. In 
addition to the processes defined above, the first year of the 
technology program also implemented a number of 
technology assessment tools. These tools are described in 
the following sections. A change in technology 
management occurred between the first and second year of 
the technology program and the tools were no longer 
implemented. The tools, however, were useful during the 
first year and warrant discussion. 


4. 1 Aggregate Project Plan (“The Bubble Chart”) 

The aggregate project plan (or as the Project Team called it, 
the Bubble Chart) maps the technical impact of each 
technology task against the risk of the task. The chart also 
includes the budget allocation and budget status of each task 
[5]. This chart allows managers to quickly assess the status 
of all technology tasks in MSL’s Technology Program. 
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Figure 4-1 - A 2002 MSL Aggregate Project Plan (Bubble Chart) 


A technology portfolio (represented by the aggregate project 
plan), like a financial portfolio, should be balanced. That 
is, the risk of developing a technology should be 
commensurate with the technology’s predicted performance 
or impact. For example, a high-risk technology should have 
a high impact and a low impact technology better have a 
low development risk. In addition, if a technology has a 
high impact, but a low development risk, maybe it should be 
moved out of the technology program and into a flight 
project. 

The aggregate project plan is updated every month with the 
latest status of the technology tasks. The bubble’s x/y- 
location corresponds to the risk/impact of the technology; 
the size of the bubble corresponds to the task’s budget, the 
color of the bubble corresponds to the task’s financial status 
(red = +/- >10%, yellow = +/- 5% to 10%, green = on 
budget); and the color of the bubble’s ring corresponds to 
the status of the task’s risk/decision analysis assessment. 
Figure 4-1 is an example of the MSL’s technology 
aggregate project plan. 

The process of creating the first MSL aggregate project plan 
(or the Bubble Chart), was a challenging process. 
Technologists don’t like to compare their technologies head- 
to-head to other technologies and want their technologies 
shown favorably in any summary chart. The x/y location of 


each bubble was assign by its Task Manager and Element 
Manager, but some Task Managers disagree with their 
relationship to other tasks. The process is subjective and 
initiated some heated debates, but the end result is a useful 
management tool to access and correct the overall 
Technology Program. 

For example, Figure 4-1 shows a high-impact, high-risk, 
task that was significantly over budget and had a budget 
status of red. This raised considerable management 
attention and both the Task Manager and Element Manager 
had to explain the issues and present a recovery plan. The 
recovery plan included reducing the future workforce, 
extending some delivery schedules, and using budget 
reserves to cover the overruns. The project reviewed the 
plan, agreed the new schedule did not significantly impact 
the project, and approved the recovery plan. In addition, the 
one large task was broken into three smaller more 
manageable tasks. 

The monthly aggregate project plan helped identify the 
problem, highlighted the impact and the risk of the task, and 
let management see the big picture before agreeing to a 
solution. If the task had a lower impact it may have been 
cancelled or not given more money. In addition, if the task 
had less risk (i.e. less challenging), but had similar 
problems, the Task Manager may have been replaced. 



The X-axis, or the Technology Impact, of the aggregate 
project plan is defined as following: 1) New Core Product - 
Fills previously unknown, unmet needs. This is the first 
introduction of a revolutionary new technology. Stimulates 
new usage and system designs; 2) New Benefits - Fills 
known but as yet unmet needs. Delivers new concepts and 
benefits that fulfill needs that are otherwise unmet by any 
technology; 3) Improvement - Better meets needs or meets 
more needs. This impact is significant, discernible 
improvement or enhancement relative to existing 
technology; and 4) Variant - Meets same needs differently. 
This is a minor revision, adjustment, and alterations with 
relative parity to existing product performance, claims, & 
features; and 5) No Change - This technology meets the 
same needs with no change. No perceived activity, but 
involving improved processes that result in cost reductions 
or meet project/program mandate with no change in quality. 

The Y-axis, or the Risk, of the aggregate project plan is 
defined as following:: 1) Radical - First use of a Technology 
that is new to the industry; 2) Next Generation - Pushes 
existing Technologies into a completely different 
application; 3) Incremental - Extends existing Technologies 
beyond the normal application; and 4) Base - Exploits 


current standard Technology without extending the range of 
applications [5]. 


4.2 Technology Funnel Chari 

The technology funnel chart maps the high-level project 
schedule against the schedule status of each the technology 
tasks (see Figure 4-2). It also captures the budget 
allocation and schedule status of each task. The funnel chart 
defines the separation between different technology 
development stages. The process provides a clear criteria 
for a technology to proceed to its next development step. It 
also provides a way to kill technology development efforts 
that is not performing technically, financially, or schedule- 
wise. The funnel chart enables program and project 
managers to engage technologists at the right time to correct 
technical and programmatic issues before they impact the 
project. It also provides a continuous process to verify that 
the technology fits with the project and program strategy 
and system architecture. The overall shape of the funnel 
chart implies that some technology tasks are eliminated as 
the project refines its implementation concept and some 
technology tasks cannot meet their requirements [5]. 
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Figure 4-2 - A 2002 MSL Technology Funnel Chart 





The primary gates (represented by horizontal diamonds) on 
the funnel chart are the yearly non-advocate reviews and the 
quarterly program reviews. These gates give technologists 
the freedom they need between gates to develop their 
technologies. This phased gate model facilitates a common 
understanding of technology task progress. The gates allow 
the project to defined, track, and review tasks according to 
predetermined decision criteria. They also give a project 
visibility across tasks and elements with standard 
terminology and simplified reporting. The selection criteria 
for a task to pass from one phase of the funnel chart to the 
next include: are key project needs identified and met; will 
the technology be delivered within budget, schedule, and 
risk constraints; and does the technology fit the project 
architecture. 

The ovals in the bottom of the funnel chart represent the 
documents the technology tasks develop to describe their 
tasks. These documents include the TDA and FFE, which 
reflect the detailed technical description of the task and the 
budget required to meet the technical requirements. The 
TDA and FFE’s are periodically update to reflect the latest 
status of the task. Significant changes to the TDA and FFE 
require approval by the MSL technology CCB to properly 
assess the impact of any changes. 

Figure 4-2 is an example of the MSL Project’s technology 
funnel diagram. The funnel chart is updated every month 
with the latest status of the technology tasks. The bubble’s 
x-location corresponds to where the technology is on the 
TRL/progress scale; the size of the bubble corresponds to 
the task’s budget, the color of the bubble corresponds to the 
task’s schedule status; and the color of the bubble’s ring 
corresponds to the technology’s TDA status. 

The funnel chart enables managers to quickly assess where 
technologies are in the development process and which 
technologies are behind schedule and require more 
management attention. 


43 Decision Analysis Tools 

The MSL Project uses a collection of Decision Analysis 
(DA) and Risk Assessment (RA) tools to manage the 
decisions and risks associated with MSL’s technology 
development program. The decision tree captures and 
analyzes both the key decisions associated with each 
technology task and the key decisions that may impact other 
technologies and the project. A typical decision tree is in 
Figure 4-3 and the decision analysis associated with this 
figure was completed for the critical decisions associated 
with some of the technology development tasks. 

Decision trees and the decision analysis process collects the 
critical decisions of the technology program; defines the 
performance, cost, and risk of each decision option; and 
establishes a date when the decision has to be made [7]. 


The decision analysis process ensures that the MSL Project 
makes intelligent and timely technology decisions. 



Figure 4-3 - The Decision Tree Analysis Tool 


In addition to the decision analysis, the MSL technology 
tasks completed a risk assessment of the key technology 
deliverables. Figure 4-4 is an example of a deliverable’s 
risk assessment. The performance, cost, risk, and date of 
each critical deliverable will be defined. If the risk of a 
technology’s deliverable is high, a backup option may be 
defined. For these critical deliverables, the development 
schedules of the primary and backup options will be 
compared and if necessary, a parallel technology 
development effort may be initiated. 
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Figure 4-4 - The Deliverable Risk Analysis Tool 


The task to modify the original Viking engines (used in the 
two 1976 Mars landings) is an example of using decision 
analysis. Early in the MSL Technology Program, the 
Project decided to modify the original Viking engine to 
increase performance rather than live with the current state 
of the art. The performance, risk, and cost of modifying the 
Viking engines, compared to the performance, risk, and cost 
of the current engines, warranted the new technology 
development effort. However, the project continued to 
monitor the deliverables of this task and if the task ever 
stumbled, the backup option and its impact on the mission 
concept would be considered. 




5. Conclusion 


8. Biographies 


The MSL Technology Program is tightly coupled to the 
MSL mission and its milestones. The program develops 
critical deliverables that must be developed in time for 
infusion into the MSL mission. The plan is to reach TRL 6 
for each technology by the mission’s PDR. This program 
transcends the usual gulf between technology and projects 
by vertically integrating the technology work with pre- 
project development in a project-like environment with 
critical dates for technology infusion. The program 
addresses developing key technology to enable MSL’s 
revolutionary science mission. 
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